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The first slide (Fig 1) represents the membership of our working 
group. You can see the diversity of people from the industry and 
government segments. Ed Filardo was the Chairman and Dave Smith 
was the Co-Chairman. 

The next slide (Fig 2) represents a summary of requirements for 
some missions in terms of both the I/O data rate in MBPS and the 
processor speed in MOPS (Mega-operations per sec) . This chart 
give you some idea of the range in fundamental computational 
requirements. For example, in the case of Galileo, we are talking 
about maybe a rather definite kick range of 1/2 MOPS and an I/O 
rate of about 1 Megabit per sec. As you move out to some of the 
more complex missions, as in the case of planetary missions like 
the Mars Rover, this requirement point moves out on the log scale 
until you get to about 5 MOPS for the processing with a 
comparable I/O rate level. And then as you go on out to some of 
the G & C (guidance and control) levels, the problems of Mars 
Rover move out at processor speed. Way at the top of the chart 
are some instrument requirements relating to EOS, where there is 
some data formatting that requires movement of data at around 200 
MBPS or more. To try to process that data on board and get the 
data rate down from 500 to 600 Megabits, this kind of compression 
will require about 100 MOPS processing level. So to do data 
compression at this kind of rate, you try to have some sort of 
data handling on board the spacecraft in terms of a fiberoptic 
network or some other technology to handle the large I/O rate. 

If you try to form a consensus of the needed processing rate 
requirements versus I/O rate it turns out you are kind of : in a 
dead box, eliminating very far out things like on-board synthetic 
aperature radar processing. So you can see that we really need 
data storage devices that will handle up to a terabit. For 
Spacecraft 2000 we need data I/O fiberoptics networks that will 
handle rates of 200, 300, or 500 Megabits per sec and processors 

at least up to 10 Mops. 
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There is a kind of gap in trying to get the processing speed, and 
NASA has been dependent on VHSIC technology, which is driven 
toward some of the military applications and not necessarily 
toward space. Also, this technology has some problems in terms of 
being single-hit upset sensitive and can not be used in space 
right now, although programs are in place to solve this and 
provide qualified VHSIC. NASA, and Harry Benz of Langley in 
particular, is trying to direct that program to solve some of our 
problems, but it should be noted that VHSIC has a ways to go. 

The next chart (Fig 3) is a comment on improvement in flight 
qualified components and families for computing. Several of our 
group feel that instead of the 1750 instruction set or maybe a 
general purpose computer to do symbolics as well as numeric 
calculations, the instruction set for the commercial size is 
preferable. In order to get there, i.e. use commercial kinds of 
derivatives of processors and so forth, we have to flight qualify 
at least the components. One of the problems we have is that 
there is about six to ten years from getting a flight qualified 
processor or parts from where the technology has been inserted. 
So we need to develop some component technology which is fast, 
insensitive to total dose of radiation, and single hit upset 
insensitive. We feel there are a couple of approaches. 

Sandia is building the 32000 chip set and the National 32000 chip 
set with their rad-hard process. That set should be available in 
the late 1990's, at least the 32 bit processor; and that could be 
switched to GaAs rather than the current CMOS. The expected 
result, if we stay with this program, is that you could get the 5 
MIPS machine and components of a processor with feature sizes 
drawn again from the VHSIC program down to about 1 micron. We 
also need high density RAMS along that same vein too, with 4K 
RAMS the only thing available now; we need also to bring off some 
high speed CMOS logic family in terms of completing the 
electronics problem. So this is a base only; you don't have to do 
it with 32000 chips and we might equally put money into other 
schemes to get a processor in the 5-10 MIPS range. 

For data storage (Fig 4) , we said that at least a terabit 
capability is needed. The spacecraft requires this and in 
addition, support rates from 10 Megabits to a Gigabit level. For 
planetary missions, the magnetic tape technology development 
program or a derivative thereof will probably suffice to achieve 
lower power and weight. The optical disk storage technology needs 
to be brought along and flight qualified for improvement in speed 
and I/O buffering, however. We should have that kind of 
technology, terabit storage and rapid access by the year 2000. 

Now, as we move ahead to Spacecraft 2000 and the desired 10 MIPS 
processor speed level, you get into parallel processing 
technology and the need for distributed operating systems that 
can manage fault tolerance (see Fig 6) . These systems must have 
selective fault tolerant modes and be capable of doing high speed 
critical calculations. The development of such flexible operating 
systems would be a big payoff for Spacecraft 2000. 
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The next chart (Fig 5) concerns software development tools, which 
all of us agree is going to be a real necessity to keep the cost 
down for Spacecraft 2000. Software is coming to dominate our 
lives and especially those tools required for generating software 
requirements, design code, test procedures, and documentation. 
There is the question of software life cycle and software 
maintenance as the total number of lines goes up. We need a 
specific identification of these tools and their requirements. As 
the spacecrafts evolve from, perhaps a common to a more generic 
type you need to be able to change the associated software and 
update it with specific tools. We are dependent right now on 
space station and SDI for developing a lot of these tools and it 
will be necessary to find some way of transferring or adapting 
these tools to other planetary programs and earth-orbiting 
programs . 

Now consider the slide on languages (Fig 7) . The Space Station 
picked the ADA language. We looked at ADA and there are some 
shortcomings with this language. However, we think for Spacecraft 
2000, ADA is still a good choice. We think some work needs to be 
done on compiler efficiency. ADA is not a really good real time 
language and has to be augmented with other special routines. 
There are some problems with interprocess communications. If you 
have to use ADA as a distributive processor, you may have to put 
these into the operating system rather than augment the language; 
this is a trade we will have to make. The objective is to get a 
higher order of language which would solve these problems and 
there is a need to study ADA extension versus standardizing on 
some other language. What those extensions are, will be very 
important to not only Space Station but to Spacecraft 2000. 

The next slide (Fig 8) concerns fault tolerance and testing. 
Fault tolerance in the past had come from triplicating and voting 
with some watchdog timers and older concepts. We need to rethink 
these, especially in light of the new distributive processing 
systems. So SDI has brought this to focus and will depend on that 
to look at fault tolerance in a new light in terms of new ideas 
and architectures. Fault tolerant concepts need to be able to 
treat flexible connectivity of distributive machines and 
especially for distributive control. 

What does that mean to fault tolerance now, with distributive 
control? You have to treat such things as brizantine failures 
(someone is lying on the voting) . When you get down to very fault 
tolerant systems, those kinds of improbable or low probability 
occurrences actually now become significant. SDI is putting a lot 
of money and resources into this arena and we want to try and 
ride their coat tails as much as possible. 

The next chart is on fiberoptics networks (Fig 9) . There are good 
programs on this subject at both Langley and Goddard. Research is 
being done at 300-500 Megabits in fiberoptic networks. What needs 
to be done in addition to continuation of these programs is the 
work to continue to flight qualify the components and the 
protocols that go along with these systems. In particular, there 
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are different kinds of electronic components that go along with 
that kind of network that have to be flight qualified. I have 
listed some of the components here, and again note we are trying 
to do from 300-500 MBPS low error rate FOLANS, which is the 
fiberoptic land network in spacecraft. 

Figures 10a and 10b are on the subject of communications 
protocol. At these rates you need real time dedicated response, 
reliable communications, and of course, we are talking very high 
band width. These are some of the characteristics of that network 
and without any one of those it is prohibitive, but you need a 
simultaneous constraint solution to solve all problems. The 
current link protocols can not handle the 100-300 Megabit band 
rate in software, and it's too complex for hardware; so new 
protocols are needed and work should be done to bring that along. 
It should be noted that this is a fairly open area at this point. 

We are concerned about security (Fig 11) , and that has to be 
looked at right now as we are talking about the operating system. 
And we are also talking about embodying some security concepts 
into the early development stages for new protocols for the 
fiberoptics networks as it is very difficult to do it at a later 
stage of development. NASA's needs in this area should be 
carefully identified. 

Finally, the last chart (Fig 12) is on technology evolvability . 
When you are trying to integrate high speed fiberoptics, 
processors, protocols, etc. you are going to need some sort of 
systems modeling. Every one of us agreed that we are lacking the 
systems tools to model such things as error rates and systems 
performance. These systems models are needed to look at the 
benefits and trades associated with technology evolution. If you 
want to replace your computer from the 16 bit to the 32 bit and 
move as the industry moves, you are going to have to design it to 
be transparent. That kind of system modeling is lacking. NASA 
needs a very firm planning program now to select and develop 
these tools. Whether there is funding from SDI or some other 
source, it needs to be a consistent plan put together by NASA. 
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SPACE COMPUTATIONAL REQUIREMENTS SUMMARY 






CURRENT FLIGHT OUALIFICATION PROGRAM LAGS 
TECHNOLOGY INSERTION BY 6 TO 10 YEARS. 

Develop fast component technology which is 
RADIATION & SEU INSENSITIVE AND FLIGHT 
OUALIFIEO BY LATE 1990'S. REESTABLISH 
COMPONENT BASE PROGRAM TO FILL GAP. 
CONTINUE TO FUNO SANDIA FOR PRODUCTION OF 
32000 NATIONAL PART SET. ADD ADDITIONAL 
HC PARTS. ADD ADDITIONAL FUNDS TO 
ESTABLISH FEASIBILITY TO TRANSITION FROM 
CMOS TO G a A s OR OTHER IN LATE 1990' S. 

FAST PROCESSOR PART SET WHICH WILL 
PROVIDE COMPUTER BUILDING BLOCKS FOR 


SPACECRAFT 2000. REDUCED FEATURE SIZE AT 
i 1/M MICRONS (FROM VHSIC THRUST) PLUS 
G a A s OR OTHER SHOULD PROVIDE 5 MIP 
MICROPROCESSOR. RAD HARD TO » 30.000 RADS 
(Sj) AND LET'S OF 37 K R . 


Figure 3. 
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DATA MANAGEMENT - DATA STORAGE 


PROBLEM? s/c 2000 REQUIRES ? 10*2 bits STORAGE AND RAPID ACCESS 
DATA BUFFERING.) DEVICE SHOULD SUPPORT RATES FROM 10 MBPS 
TO 1 GBPS. 

OBJECTIVE? DEVELOP LOW-POWER/ WEIGHT MAGNETIC TAPE TECHNOLOGY FOR 
TERABIT RECORDER. BRING OPTICAL DISK DEVICE TECHNOLOGY 
ALONG FOR HIGH-SPEED BUFFER. 

APPROACH? DEPEND ON CURRENT PROGRAM AT ODETICS FOR TAPE RECORDERS. 

AUGMENT TO REDUCE POWER AND WEIGHT. CONTINUE RCA SUPPORT 
TO OPTICAL DISK DEVICES: LOOK AT FLIGHT QUALIFICATION ISSUES. 

EXPECTATIONS: SHOULD have flight qualified storage devices for 

s/c 2000 WHICH CAN SUPPORT TERABIT STORAGE AND HIGH RATE 
BUFFERING. 

Figure 4. 


DATA MANAGEMENT — SOFTWARE DEVELOPMENT TOOLS 

PROBLEM ? SPACECRAFT FLIGHT. PROGRAMS IN THE YEAR 2000 WILL BE PROHIBITIVELY 

EXPENSIVE TO ENGINEER; DEVELOP, TEST AND MAINTAIN WITH THE SOFTWARE 
DEVELOPMENT TOOLS CURRENTLY IN USE. 


develop an integrated software engineering and development 

ENVIRONMENT ASSISTED BY EXPERT SYSTEM TECHNOLOGY FOR AIDING IN THE: 
0 GENERATION OF SOFTWARE REQUIREMENTS, DESIGN, CODE, TEST CASES, 
TEST PROCEDURES AND DOCUMENTATION. 

0 CONFIGURATION MANAGEMENT OF THE SOFTWARE. 

0 IDENTIFICATION OF DESIGN, CODE, TEST CASE AND DOCUMENTATION 
CHANGES DICTATED BY REQUIREMENTS CHANGES. 

0 LEARNING THE SOFTWARE SYSTEM (INTERACTIVE, USER-FRIENDLY 
ELECTRONIC "USER'S MANUAL"). 


APPROACH : 1. MONITOR THE DEVELOPMENT OF SUCH TOOLS BY SPACE STATION, SDI AND 
INDEPENDENT INDUSTRY INITIATIVES. 

2. INITIATE NASA PROGRAMS FOR DEVELOPING SUCH TOOLS IF OTHER AGENCIES 
DO NOT. 


EXPECTED RESULTS : 

REDUCE SOFTWARE DEVELOPMENT AND MAINTENANCE COSTS BY AN ORDER OF 
MAGNITUDE. 


D. BRADY 


Figure 5. 
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DATA MANAGEMENT - OPERATING SYSTEMS 


PROBLEM ; THE NEED EXISTS FOR A DISTRIBUTED OPERATING SYSTEM WHICH HELPS MANAGE SYSTEM 

FAULT TOLERANCE AND WHICH CAN ITSELF SWITCH IN AND OUT OF HIGHLY FAULT TOLERANT 
CONFIGURATIONS AS A FUNCTION OF SOME SOFTWARE OR SYSTEM CONDITION. 


OBJECTIVE ; DEVELOP AN OPERATING SYSTEM PORTABLE TO THE ON 'BOARD COMPUTERS OF THE YEAR 2000 
WHICH PROVIDES THE FACILITIES FOR 
0 RELIABLE INTERPROCESSOR COMMUNICATION 

0 SYNCHRONIZATION OF COMMUNICATING TASKS BOTH ON THE LOCAL PROCESSOR AND ON 
OTHER PROCESSORS IN THE SYSTEM 

0 SYSTEM UTILITIES TO ASSIST IN FAULT MANAGEMENT OF THE SYSTEM. PARTICULARLY 
RECOVERY FROM FAULTS IN COMMUNICATING PROCESSORS. 

0 SELECTABLE FAULT TOLERANCE MODES FROM MINIMAL FAULT TOLERANCE TO 
TRIPLICATION AND VOTING. 


APPROACH ; i. DEFINE SPECIFIC FEATURES AND REQUIREMENTS FOR THE VARIOUS FAULT TOLERANCE 
MODES, INCLUDING METHODS FOR ACHIEVING SOFTWARE FAULT TOLERANCE. 

2 . DEFINE REQUIREMENTS FOR THE REMAINDER OF THE OPERATING SYSTEM. 

3. SPONSOR THE DESIGN. DEVELOPMENT AND TESTING OF THIS OPERATING SYSTEM. 


EXPECTED RESULTS I 

SHOULD HAVE FAULT TOLERANT, DISTRIBUTED OPERATING SYSTEMS TO SUPPORT SINGLE OR 
MULTIPLE NODE COMPUTERS. 

D. BRADY 


Figure 6. 


DATA MANAGEMENT — LANGUAGES 

PROBLEM : THE STANDARDIZATION ON ADA WITHIN DOD AND NASA LEAVES ON-BOARD SOFTWARE 

DEVELOPERS WITH SEVERAL CONCERNS: 

0 EFFICIENCY AND MATURITY OF THE COMPILER. 

0 SHORT COMINGS OF THE LANGUAGE FOR REAL-TIME CONTROL APPLICATIONS. 

0 SHORT COMINGS OF THE LANGUAGE FOR INTERPROCESS COMMUNICATION AND 

SYNCHRONIZATION. 

OBJECTIVE : DEVELOP A HIGH-ORDER LANGUAGE (HOL) WHICH MORE EASILY MEETS THE 

REQUIREMENTS OF A REAL-TIME., INTERACTIVE DISTRIBUTED PROCESSING SYSTEM 
WITH A MATURE, EFFICIENT COMPILER BY THE YEAR 2000. 

APPROACH ! 1. FUND A STUDY TO TRADE THE VIABILITY OF EXTENDING ADA VERSUS 

STANDARDIZING ON SOME OTHER LANGUAGE WHICH IS MORE APPROPRIATE 
TO THIS APPLICATION. 

2. IF ADA IS SELECTED, DEFINE A SET OF "STANDARD" EXTENSIONS TO THE 
LANGUAGE WHICH MEET OUR REQUIREMENTS. 

EXPECTED RESULTS : 

AN ADA VARIATION WHICH WILL STANDARDIZE SOFTWARE DEVELOPMENT FOR 
S/C 2000 AND BEYOND. 


D. BRADY 




Figure 7. 
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DATA MANAGEMENT -- FAULT TOLERANCE AND TESTING 


PROBLEMS/NEEDS : 

0 SIMPLER FAULT DETECTION. ISOLATION. AND RECOVERY TECHNIQUES UHICH RETAIN 

ADHERENCE TO FUNDAMENTAL REQUIREMENTS (E6, P p >10 9 /HRi DATA CONGRUENCY. 
CORRELATED. TRANSIENT, BRIZANTINE FAILURES. ETC.) 

0 FLEXIBLE CONNECTIVITY AND CONTROL FOR DISTRIBUTED. TIME CRITICAL. INTERACTIVE 

PROCESSING 

0 TRUSTWORTHY SOFTWARE VIA "FAULT" TOLERANCE i PERHAPS EVENTUALLY VIA ERROR-FREE 

CODE 

0 INTEGRATION OF SECURITY (EG. MARKOV) FOR EVALUATION. VERIFICATION. S> MODIFICATION 

0 EXTENSION OF TECHNIQUES TO NON-GENERAL PURPOSE ARCHITECTURES (MASSIVE PARALLEL. 

DATA FLOW) 

0 INCORPORATION OF NEW COMPONENT TECHNOLOGIES (VHSIC G^Aj, ETC.) 

OBJECTIVE . 

REDUCE RISK OF TECHNOLOGY SHORTFALL IF "COATTAILS" DON'T MATERIALIZE. 

APPROACH . 

MONITOR AND. IF/WHERE NECESSARY. AUGMENT ONGOING PROGRAMS (EG SDl) VIA SELECTED 
DEVELOPMENT AND 6ROUND-BASED TEST BED DEMONSTRATIONS. 

EXPECTED RESULTS . 

MATURE TECHNOLOGY BASE IN ALL AREAS ABOVE BY MID-LATE 90'S. 

M. W. JOHNSTON 10/20/86 


Figure 8. 


DATA SYSTEMS - FIBER OPTIC NETWORKS 

PROBLEM . 500 MB FIBER OPTIC SPACECRAFT LOCAL AREA NETWORKS ARE NOT AVAILABLE TO 

SPACECRAFT SYSTEMS BECAUSE OF THE LACK OF SPACE QUALIFIED COMPONENTS. 

OBJECTIVE . TO SPACE QUALIFY SEMICONDUCTOR LASER TRANSMITTERS. P'l’N RECEIVERS. ANALOG 
CONDITIONING AND STABILIZING CIRCUITRY. AND OPTICAL ELEMENTS NECESSARY TO 
IMPLEMENT SPACE QUALIFIED FIBER OPTIC LOCAL AREA NETWORKS (FOLAN) IN THE RANGE 
OF 300-500 MBT/SEC. 

APPROACH . TO SPACE OUALIFY SINGLE MODE FIBER OPTIC CABLES. CONNECTORS. 

TO SPACE OUALIFY LASER TRANSMITTERS. P'l'N RECEIVERS. 

TO DEVELOP AND SPACE OUALIFY PACKETIZATION, AND PROTOCOL DECISION MAKING LOGIC. 

QP-ECTEO RESULTS. 

COMPONENT TECHNOLOGY BASE TO ASSURE 300-500 MBPS LOW ERROR RATE FOLAN’S FOR 
SPACECRAFT. 


Figure 9. 
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DATA MANAGEMENT — COMMUNICATION PROTOCOLS 


PROBLEM : SUCCESSFUL INSERTION OF PACKET-SWITCHING TECHNOLOGY INTO SC-2000. 

OBJECTIVE : REPLACE A MAJORITY OF SPECIAL CABLING IN SPACECRAFT WITH A 

PACKET-SWITCHED, SHARED COMMUNICATION MEDIUM (PROBABLY FIBER OPTICAL 
LOCAL- AREA-NETWORK BASED). MOST POINT-TO-POINT CABLES WOULD BE REPLACED 
BY A TAP INTO THE MEDIUM. 

ISSUES : THIS TECHNOLOGY IS BEING DEVELOPED PIECEMEAL TODAY IN MANY LOCATIONS. 

HOWEVER, THE CONSTRAINTS FACED IN SC-2000 &g£ ME ADDRESSED BY EXISTING 
PROGRAMS. THE SC-2000 CONSTRAINTS/REQUIREMENTS INCLUDE: 

0 REAL-TIME GUARANTEED RESPONSE 
0 PRIORITY FOR CRITICAL COMMUNICATIONS 
0 SUBSUMING (ALMOST) ALL POINT-POINT COMMUNICATIONS 

ON THE SPACECRAFT 

0 RELIABLE COMMUNICATIONS (WELL BEYOND THE BIT ERROR RATE 
OF THE COMM. MEDIUM) 

0 VERY HIGH BANDWIDTH 

0 SINGLE INSTRUMENTS 100-300 MBAUD 

0 REPLACING TDM FOR MOST USAGES 

• WHILE NO CONSTRAINT ABOVE IS PROHIBITIVE, THE SIMULTANEOUS SOLUTION OF 
AIL OF THEM IS BEYOND CURRENT TECHNOLOGY . 

Figure 10a. 


DATA MANAGEMENT — COMMUNICATION PROTOCOLS (CONTINUED ) 

• CURRENT LINK-LEVEL PROTOCOLS CANNOT HANDLE 100-300 MBAUD IF 

IMPLEMENTED IN SOFTWARE, AND ARE TOO COMPLEX TO IMPLEMENT IN HARDWARE. 
NEW PROTOCOL(S) ARE NEEDED. 

0 THE ABOVE IS EVEN MORE TRUE OF TRANSPORT-LEVEL PROTOCOLS, WHICH 
ARE FAR TOO SLOW. A NEW PROTOCOL IS NEEDED HERE, TOO. 

APPROACH : NASA SHOULD FUND A SC-2000 BRASSBOARD IMPLEMENTATION, SOLVING ALL THE 
ABOVE CONSTRAINTS SIMULTANEOUSLY IN A SYSTEM WHICH CAN BE THE TEST BED 
OR PROTOTYPE FOR THE PROTOCOLS, CHIPS, COMMUNICATION MEDIUM, OPERATING 
SYSTEM, FAULT DETECTION/RECOVERY, ETC. 

EXPECTED RESUIT : 

THE OUTPUT INCLUDES: 

0 NEW PROTOCOLS 

0 NEW COMM. CHIPS 

0 WORKABLE ALGORITHMS AND STRATEGIES FOR FAULT TOLERANCE 
0 WORKING OPERATING SYSTEM SOFTWARE 

WITHOUT THE EARLY AVAILABILITY OF THIS TECHNOLOGY, SPECIAL INTERESTS WITH SPECIAL 
NEEDS WILL FORCE MULTIPLE NON-STANDARD INTERFACES INTO SC-2000, DUE TO THEIR 
OWN NEED FOR EARLY DESIGN FREEZES. THIS WILL MAKE THE NECESSARY COMMONALITY OF 
INTERFACE AND OF STANDARDIZATION IMPOSSIBLE. 

Figure 10b. 
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DATA MANAGEMENT — SECURITY 


PROBLEM : SC 2000 WILL HAVE TO SUPPORT a wide range of users, many of which will 
HAVE STRINGENT DATA SECURITY REQUIREMENTS. THESE REQUIREMENTS CANNOT 
BE MET BY PRESENT SYSTEMS. 

OBJECTIVE : IDENTIFY SC 2000 SECURITY REQUIREMENTS IN DETAIL. PRODUCE A FORMAL 

SECURITY POLICY. INSURE THAT THE NEEDED SECURITY TECHNOLOGY IS AVAILABLE 
AND IS UTILIZED DURING THE SYSTEM DEFINITION PHASE. 

APPROACH : NASA SHOULD BEGIN INTERACTIONS WITH THE NATIONAL SECURITY AGENCY AND THE 
NATIONAL COMPUTER SECURITY CENTER TO IDENTIFY NASA'S NEEDS IN SEVERAL 
AREAS: 

— SOFTWARE SECURITY (ESP. COMM & OPERATING SYS.) 

-- COMMUNICATIONS SECURITY 

-- OPERATIONS AND DEVELOPMENT INTEGRITY ASSURANCE 

EXPECTED RESULTS : 

SECURITY ISSUE IS INCORPORATED DURING EARLY DEVELOPMENTS OF PROTOCOLS 
AND OPERATING SYSTEMS. 

-- IF NOT BEGUN NOW, SECURITY IS HARDER (OR IMPOSSIBLE) TO ADD LATER. 

-- SECURITY & FAULT TOLERANCE MAY BE COMPLEMENTARY (EG, CRYPTOGRAPHIC 
CHECKSUMS MIGHT AUGMENT OR REPLACE OTHER ERROR DETECTION CODES, 

WITH ADDED VALUE FROM RESULTING INTEGRITY CHECKS). 

Figure 11- 


DATA MANAGEMENT — TECHNOLOGY EV0LVABILI1Y BY TRANSPARENCY 


1 . 


2 . 


3. 


PROBLEM: 


OBJECTIVE: 


APPROACH: 


SUBSYSTEM HIERARCHICAL MODELS NEED TO BE EXERCISED IN A SYSTEM WIDE 
MODELLING TOOL. MODELLING RESULTS MUST BE VALIDATED IN A TEST BED 
PRIOR TO SUBSYSTEM INTERFACE/PROCESSOR-MEMORY-SOFTWARE PARTITIONING. 
HEURISTIC METHODS CURRENTLY IN USE CAUSE OVERDESIGN/UNDERDESIGN 
PROBLEMS AT SUBSYSTEM INTEGRATION. SYSTEMS MUST BE COMPLETELY 
REDESIGNED TO ACCOMMODATE TECHNOLOGY UPGRADES. 

SIGNIFICANT ARCHITECTURAL MODELLING TOOLS AND METHODOLOGY NEED 
DEVELOPMENT. PARTICULAR MODELS NEED TO BE DEVELOPED FOR PROCESSOR, 
STORAGE AND SOFTWARE. TEST BED DEVELOPMENTS MUST BE INITIATED TO 
MEASURE MODEL PARAMETERS AND VALIDATE END TO END MODELS. 

* SELECTION OF METHODOLOGIES/HIERARCHICAL TOOLS 

* DEVELOP TOOL - MODEL ELEMENTS 

* ACQUIRE TEST BED ELEMENTS 

* INTEGRATE WITH OTHER SUBSYSTEMS & SUBSYSTEM MODELS 

* ITERATE SYSTEM CONFIGURATIONS/TOPOLOGIES TO GIVE VALIDATED DESIGNS 


4. EXPECTED 

RESULTS: * FIRM PUNNING SYSTEM/SUBSYSTEM INTERFACE DEFINITIONS 

* SPECIFICATIONS FOR SUBSYSTEM DEVELOPMENTS 

* SYSTEM DESIGN MODELLED AND VALIDATED 


Figure 12. 
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